NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/1288

Internet Message Format | 1996-08-06 | 4.9 KB

Path: mujibur.inmind.com!usenet
From: [e-mail]
Newsgroups: comp.lang.c++
Subject: Re: Hungarian notation
Date: 10 Jan 1996 08:48:08 GMT
Organization: In Mind, Inc.
Message-ID: <4cvug8$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <4c44dh$[e-mail]> <4c477m$[e-mail]> <4ccq2u$[e-mail]> <4cmblb$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: finneyman.inmind.com
X-Newsreader: IBM NewsReader/2 v1.2

In <4cmblb$[e-mail]>, [e-mail] (Warren Young) writes:
>Of course.  These were merely examples of well-known functions where
>passing the new string would cause problems.  You asserted that the
>semantics didn't change, and I just dashed off some examples that
>disproved that.

You mistaketh me for someone else, sirrah!  The post you quoted
was my FIRST post, so you couldn't have been replying to a previous
message by me.

>printf() is kinda obsolete.  If you are dealing with wide character types
>>you are almost certainly not going to be using printf().
>
>Your example was converting an existing "standard" string into a wide
>character string by prefixing it with L.  So, it's very likely that
>the original program was using something that wanted regular strings,
>and the change will probably stop it working from right.

Not at all.  Just because you are using "regular" strings does
not mean that you are using printf() or any other function
which does not have the approprite overloaded definitions.
Although, it certainly MAY make things stop working.  But
that is an issue of type dependence which should be addressed
directly.

>Sure, you can do the compile-and-grep thing until it finally compiles,
>but this method can fail you, because of the usages can be missed.
>Between strong type checking, lack of vararg functions and careful
>coding habits, you can be assured that the compiler will catch most of
>the problems, but it's always those little things that the compiler
>thought were copacetic that get you.
>
>If you're using HN, you will be _forced_ to visit every usage of that
>variable.

The "grep and compile" approach -- or load ALL source files into
your editor and perform a global, multi-buffer search will also
visit all occurences.  If that is appropriate.  I don't need HN for
that!

>If you care enough about types to be using a
>well-considered HN variant (I'm not talking about that Petzoldian
>alphabet hash), you'll probably take the opportunity to make sure that
>the semantics are still OK.  I know of no better way of encouraging
>this than HN.

I would disagree here.

>I agree, and if this is heeded religiously, it completely solves type
>compatibility problems for C++ houses.  In other, less perfect
>environments, such as C-only houses and those where you can't count on
>everyone to follow the rules, HN is useful.

Since when is C any less type safe than C++?  I don't know about
you, but I haven't seen a K&R type C program in years and years.
If you use ANSI C with function prototypes then you have most of
the type safety of C++.  The primary except being the ability to
convert a void pointer to any other pointer without an explicit
type cast.

>HN also has another
>mission, and that is to encourage programmers to consider semantic
>issues more carefully, especially in cases where the code mixes types
>and yet compiles without warning.  Your rule does nothing in this
>regard.

I expect to mix types and have clean compiles!  Anywhere I mix
types I better have the appropriate type compatabilities.

>The only excuse I can think of for not having constant folding turned
>on is if your code is taking and using the address of a constant.  If
>you're doing that, though, you have no sense of style anyway.
>(Whether by your choice or Fate's, the result is the same.)

I don't know about you, but not only do I turn type folding on, but I
also force as many literals as possible into system read-only memory.
When "const" was added to the language, it was a big mistake to
allow literals to have a type which was not "const".  Sure, it would
have broken a bit of code -- but that would have been minimized by
supplying the appropriate variants of the library functions.

But "using the address of a constant" as bad style.  This is
mandatory for string constants which ARE an address, and
for other literals anytime you have to pass something by
reference the address will be taken (implicitly, at least).

>It goes away with inline functions, too, becase you're likely to be
>using conditional compilation to switch the various versions of the
>inline wrapper in and out.  _I_ would be, anyway....

And, in many cases inline functions are the right approach.  But
not necessarily the only approach or the best approach.


Michael Lee Finney